-
Notifications
You must be signed in to change notification settings - Fork 34
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Allowing for multiple events of same name to be raised in parallel #194
Conversation
Signed-off-by: Ryan Lettieri <[email protected]>
Signed-off-by: Ryan Lettieri <[email protected]>
Signed-off-by: Ryan Lettieri <[email protected]>
eng/proto
Outdated
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think this change here was intentional, was it?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM but some minor fixes
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Please address the warnings before checking in.
src/Worker/Core/Shims/TaskOrchestrationContextWrapper.EventSource.cs
Outdated
Show resolved
Hide resolved
@@ -14,7 +14,7 @@ namespace Microsoft.DurableTask.Worker.Shims; | |||
/// </summary> | |||
sealed partial class TaskOrchestrationContextWrapper : TaskOrchestrationContext | |||
{ | |||
readonly Dictionary<string, IEventSource> externalEventSources = new(StringComparer.OrdinalIgnoreCase); | |||
readonly Dictionary<string, Queue<IEventSource>> externalEventSources = new(StringComparer.OrdinalIgnoreCase); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I am not sure what the typical event usage is, but I am going to hazard a guess single events are common. In which case allocating a queue for it is not optimal. We will have to revisit this and see if there is a way to optimize for a few element count cases.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Agreed we should revisit this. It turns out we do the same thing with the NamedQueue<string>
class for buffered events, so we should consider optimizing both.
This change stems from the following issue discovered in dapr: dapr/dotnet-sdk#1129